約 3,753,620 件
https://w.atwiki.jp/atwikimyj/pages/45.html
いままでは何の苦労もなく使い続けられていたCgi Liteだが、ファイルのアップロードを させようとすると一転して問題児に。 multipartがうまくよめないようだ、、。 ということでCGI.pmを使うことに。 CGI Liteでは簡単だった%FORM処理だがCgi.Pmは古いためか もう1アクション必要。 use CGI; $query = new CGI; my %FORM; foreach ($query- param) { $FORM{"$_"} = $query- param($_);} まあこれだけですんで、さらにファイルのアップロードにも対応するのだから 文句は言えない。 あとはCGI.pmの解説サイトをみてください。
https://w.atwiki.jp/atwikimyj/pages/25.html
参考 [http //d.hatena.ne.jp/ZIGOROu/20061105/1162736838] CPAN [http //search.cpan.org/~mschilli/Log-Log4perl-1.10...] use宣言 use Catalyst Log Log4perl; ※Catalystのプラグインではない。 * log吐き出し先ファイルを設定(confのパーミッションを775にしてね) PACKAGE- log(Catalyst Log Log4perl- new("/var/www/vhosts/hoge.net/conf/log4perl.conf")); #PACKAGE setup; わからないけどsetupのメソッドを使うとエラーになる(なぜかDB内のUserテーブルが読めない!というエラー なんなんだ。。) エラーログにエラーが出る Log Log4perl configuration looks suspicious No loggers defined at /usr/local/lib/perl5/site_perl/5.8.8/Log/Log4perl/Config.pm line 308., referer http //hoge.net/user/Login/ ロガーを定義していないと思う、、とかわいいログが残っている。 confに何もかかれていない。でもエラーログにはいつもよりいろんなログが 出るようになった。 これでいいような。。。confの意味は?
https://w.atwiki.jp/0x0b/pages/83.html
CGI(Common Gateway Interface) ウェブサーバ上でユーザプログラムを動作させるための仕組み。現存する多くのウェブサーバプログラムはCGIの機能を利用することができる。 ウェブサーバプログラムの機能の主体は、あらかじめ用意された情報を利用者(クライアント)の要求に応じて送り返すことである。そのためサーバプログラム単体では情報をその場で動的に生成してクライアントに送信するような仕組みを作ることはできなかった。 そこでサーバプログラムから他のプログラムを呼び出し、その処理結果をクライアントに送信する方法が考案された。それを実現するためのサーバプログラムと外部プログラムとの連携法の取り決めがCGIである。 CGIは環境変数や標準入出力の扱える実行環境からであればプログラミング言語の別を問わず幅広く利用できるが、実行速度やテキスト処理の容易さなどの兼ね合いによりPerlが使われることが多かった。近年では、Perlに加えてPython、Rubyなども広く使われている。 代表的なアプリケーションには、電子掲示板、アクセスカウンタ、WikiやBlogシステムなどがある。 近年では、Webサーバのプロセスとしてインタプリタを常駐させておくことにより、CGIからプログラムを呼び出すオーバヘッドを減らし、パフォーマンスを向上させたJava Servletやmod_perl、mod_php、FastCGI、WSGIなどのインタフェース・実装も出現している。 仕様 CGIの仕様はNCSAにより最初に定義・実装(NCSA HTTPdにおいて)され、現在の最新版はCGI1.1である。2004年にRFC 3875となった。 RFC3875 The Common Gateway Interface (CGI) Version 1.1 CGIは、典型的には以下のような動作を期待される。CGIを経由して実行されるプログラムのことを、CGIプログラムと呼ぶ。 CGIプログラムはウェブサーバがクライアントからのリクエストに応じて起動する。 典型的には、ウェブサーバの公開領域に置かれたプログラムに対応するURIへのリクエストがあると、サーバはそのプログラムをCGIの取り決めに従って呼び出す。 CGIプログラムへの情報の入力は、コマンドライン引数、環境変数、標準入力によって行われる。 ウェブサーバがプログラムを呼び出す時点でいくつかの環境変数を定義することが定められている。 特に、クライアントがサーバに要求したURIのうち、検索文字列(Query String)部が環境変数 QUERY_STRING に設定されるので、これはHTMLフォームからGETメソッドで入力を受けるのに便利である。 QUERY_STRINGに文字 = が含まれない場合は、サーバはQUERY_STRINGの内容をコマンドライン引数としてCGIプログラムに渡す。これはHTMLのISINDEX要素を用いて送信された情報を扱うのに便利である。 クライアントからのHTTPリクエストのBODY部はCGIプログラム標準入力に流し込まれる。また、その入力の長さが環境変数CONTENT_LENGTHに設定されている。これはHTMLフォームからPOSTメソッドで入力を受けるのに便利である。 CGIプログラムに対応する仮想パスの後に、更に余分のパスが続いた場合、その情報は環境変数 PATH_INFO に格納され PATH_INFO をウェブサーバの仮想パスと解釈した際に対応すべき物理パスが環境変数 PATH_TRANSLATED に格納される。この方式もまたCGIプログラムにユーザー側からパラメータを渡す目的でよく用いられる。 プログラムが標準出力に出力したデータは、ウェブサーバを経由してクライアントに送られる。このデータは正当なHTTPヘッダで始まらなければならない。 ただし、いくつかの特別なヘッダフィールドは「サーバディレクティブ」として解釈され、ウェブサーバの挙動(ステータスコードなど)に影響を与える。これ以外の全てのヘッダフィールドはそのままクライアントに送信される。 現在のWWWではHTMLが中心的な役割を果たしているので、CGIプログラムはHTMLを出力するケースが圧倒的に多い。 画像データなどを出力することもある(これはアクセスカウンタなどを作る際に使われる)。 The CGI Specification(archive.org) RFC 3875 The Common Gateway Interface (CGI) Version 1.1 RFC 1630 Universal Resource Identifiers in WWW RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 サーバサイドスクリプト Webプログラミングでは、サーバ側で動作するプログラムとクライアント側で動作するプログラムの両方を開発しなければならない 例としてサーバサイトにつかう言語と環境としてCGI + PerlやPHP、Ruby、Java Servlet + JSP + Enterprise JavaBeans + Spring Framework + Apache Struts(Java EE)、.NET(ASP.NET(C#,VB.NET))などが挙げられる。 サーバサイドでのプログラミングには次のような特徴がある。 アクセスが殺到しやすいウェブサイトではデータベースに高い負荷がかかりがちであるため、その解決のためにDBMSの知識がソフトウェア開発において求められることが多い。さらに金融系や基幹系業務やB2Bなどミッションクリティカルな領域での開発ではフロントエンドだけでなくバックエンドの開発も行うためUNIXやサーバ、ネットワーク、セキュリティ、計算機科学、ソフトウェア工学の知識が求められる事が多い。 またサーバサイドのプログラムでは多くの場合、複数ユーザの操作に応じた処理が同一プロセスのメモリ空間上で行われるので、ユーザごとに適切にメモリ上の情報が分離されるよう意識してプログラミングしなければならない。例えばJava ServletやJSPでクラス変数を不適切に使用して、そのサーブレットにアクセスする複数のユーザがその変数を共有してとんでもない事態に発生するミスも過去に実際起きている。この変数がもし銀行口座の預金残高などに使われていた場合、その事態は顧客やエンドユーザーからの信用を徹底的に失うほど非常に深刻なものとなる。 クライアントサイドスクリプト クライアント側のプログラミングは困難となりがちである。これを省力化するためのライブラリが様々に用意されており、例としてJavaServer Facesの部品として利用可能なライブラリAjaxFaces、JSPカスタムタグライブラリとして導入できるAjaxTags、JSP, JSF両方で利用可能なAjaxAnywhere等がある。なお、これらはいずれもAJAXを実現するライブラリで、これらを用いることでJavaScript等によるクライアントサイドのコードの開発に比重を置くことなく、リッチなウェブアプリケーションを開発できることが期待できる。 クライアントサイドでのプログラミングは、Ajax(JavaScript + XML)のようにウェブブラウザ上で動くプログラミング言語を用いて行われるケースもあるが、近年ではリッチクライアントが登場し、ウェブブラウザのかわりにブラウザ依存を避けられるJava Web StartやClickOnceやAdobe Flashを使うケースも増えている。 JavaScriptを用いる場合、ウェブブラウザには様々な実装系があるため[3]、クライアント側のでプログラミングを行うためには、複数の実装系に精通している必要があった。しかし、JavaScriptに使用されているAjaxがGoogle Mapsに実装されることで脚光を浴びるにつれて、Ajaxに使用する(prototype.jsなどの)ライブラリが、ブラウザ依存しにくいように設計されるようになってきた。Ajaxのライブラリ、フレームワークを使いこなしていれば複数の実装系依存に拘る必要は無くなってきている。 従来では、Web開発におけるクライアントサイドといえば、WebデザイナがHTMLと小規模なJavaScriptやAdobe Flashで作られたサイトを開発する程度のものであったため、オブジェクト指向プログラミングの習得についてほとんど意識する必要がなかった。しかし端末ハードウェアの性能が向上し、HTMLクライアントの限界と不満が叫ばれるようになってゆき、Ajaxとリッチクライアントが注目されるにつれて、クライアントサイドでもオブジェクト指向プログラミングを習得する必要性が高まってきた。リッチクライアントに使用する技術の一つであるSwingなどによるGUI開発ではオブジェクト指向プログラミングは、ファットクライアント、スタンドアロンアプリケーション時代から必須のものである。またAjaxのフレームワークの多くはオブジェクト指向プログラミングで設計されている[4]。 ウェブブラウザはウィンドウシステムやウィジェット・ツールキットとは異なり、アプリケーションがGUIを実現できるようにする事を元来の目的とするプログラムではなく、Web上のHTML文書などを閲覧することを主な目的とするプログラムなので、そのプログラム上で良いGUIを実現するには様々な工夫が求められる。その工夫の例としてAjaxやリッチクライアントがある。 リッチクライアント HTMLクライアントの欠点を補うために、HTMLクライアントとクライアントサーバシステムで使われてきたファットクライアントとの中間に位置するリッチクライアントも注目されている。リッチクライアントとして挙げられるものは、Java Web Start、.NETのClickOnce、AdobeのAIRなどがある。これらの登場により、クライアントサイドの開発は一変しつつある。 Perl PHP Ruby
https://w.atwiki.jp/atwikimyj/pages/88.html
PLESK環境での話。 某PLESK環境のVPSでmod_perl2を使おうとしたが、 ApacheはVersion2なのだが、mo_perlが1.99だった。 ということでmod_perl2にアップグレードする。 このサイトを思いっきり参考にさせていただきました。 isoya9の日記 Linux CentOS4 に mod_perl 2.02 をインストールす>る 1.apxsをインストール 確認すると下記のパスに /usr/sbin/apxs が存在。つまりapxsがインストールされていたので次の工程へ。 2.既存 Apache2 API を削除 $ find /usr/lib/perl5 -name Apache2* -exec rm -rf {} \; $ find /usr/lib/perl5 -name Apache2* -exec ls -lR {} \; perlライブラリ内のApache2関連のAPIを根こそぎ削除しています。 実行後は何も表示されません。 3.mod_perl2の入手とインストール Apacheのmod_perlのページ からインストールをします。 ほかのアプリケーションと同じように、ダウンロード、 解凍、make、make test、make installでOK。 途中でapxsのパスを聞かれるのでインストールした 時のパス(/usr/sbin/apxs)を入力する必要があります。 ここでmod_perl2がインストールされているかチェック #!/usr/bin/perl print "Content-Type text/plain\n\n"; print ($ENV{ MOD_PERL } || ERROR ); 上記のような簡単なスクリプトを作成し、 mod_perl_test.pl と名づけ(今回のPLESK環境では拡張子plで のみmod_perl2による動作をすることになっ ている)、実際に実行してみる。 mod_perl/2.0.3 というような表示がされればとりあえず バージョンアップに成功。だめな場合は ERRORが出るので次の作業に。 4.CPANからmod_perl2をインストール もし3までの作業で、mod_perl2が動かなかったら apacheのエラーログを見てみる。PLESK環境であれば virtualHostのエラーログとなる。 /var/www/vhosts/DOMAINNAME.COM/statistics/logs の中のerror_log になるだろう。 その中に failed to resolve handler `ModPerl Registry Can t locate ModPerl/Registry.pm in @INC (@INC (略) というようなエラーが出ていたら、たぶん、 mod_perl2用のモジュールを入れる必要がある。 ということで $perl -MCPAN -e shell \ cpan install mod_perl2 ここで、インストールに失敗する場合はたぶんroot権限で サーバにログインしてこの作業をしようとしているのでは ないかと思われる。その場合は途中で出てくるテストを すべてスキップする。 [warning] result [ error] You are running the test suite under user root . Apache cannot spawn child processes as root , therefore こんなwarningが出るのでここでスキップするか聞いてくるので YESを選ぶとスキップできる。 また、この作業の中で /usr/lib/httpd/modules/mod_perl.so というファイルを作成しようとするが、すでにこのファイルが 存在する場合はエラーになってしまう(そういうメッセージが 出る) その場合は上記のファイルをリネームして再度この作業を 実行させればよい。 これで再度 mod_perl_test.pl を実行してみるとおそらくmod_perlのバージョンが表示される はずである。
https://w.atwiki.jp/atwikimyj/pages/38.html
mod_perl2では実行しているスクリプトのあるディレクトリを カレントディレクトリとして認識してくれないので面倒! という記事によくあたる。へえ、それ面倒だな、、と思っていたが、 いろいろと調べるとそうとは限らないようだ。 カレントディレクトリがどうなるかは、動作モデルによるらしい。 参考: TurboLinux「Apache MPM を変更する」 http //www.turbolinux.co.jp/support/document/knowledge/627.html えーっと、Apache2では動作モデルがいっぱい選択できる。その中の prefork動作とWorker動作について説明すると、、 prefork動作ではクライアントからのリクエストがある度 に子プロセスを作成する。 Worker動作では複数のプロセスとスレッドによりリクエストを処理します。 複数のスレッドは同じメモリを共有し、連携して処理が行われます。 スレッドってなんじゃい?linuxでのマルチスレッド、マルチプロセスの話は hatenaの伊藤さんが詳しく説明されています。 Hatena Diary naoya「マルチスレッドのコンテキスト切り替えに伴うコスト」 http //d.hatena.ne.jp/naoya/20071010/1192040413 (社内勉強用の資料のようです。いいなあ。はてな入ってperlやりてえなあ でもこの資料まともに読めない自分のような人間は必要ないだろうなあ) preforkは従来のmod_perlと同じやり方となり、安定性がある。 worker動作をさせたほうが、効率的で、処理が速い、らしい。 よほどの理由がない限り、worker動作を使いこなせるはずもない。 また、preforkはスクリプトのあるディレクトリをカレントディレクトリ として認識してくれるので、やはりこちらか。ということで、 下記のサイトを参考にPrefork専用のハンドラーを利用するということにする。 adiary開発日誌「2006/04/15(土) mod_perl で chdir」 http //adiary.blog.abk.nu/07 TransFreeBSDの日記 「[perl]ModPerl {PerlRun,Registry,RegistryPrefork}でのカレントディレクトリ、BEGINブロック、@INCの扱いメモ」 http //freebsd.g.hatena.ne.jp/TransFreeBSD/20061124/p1 日誌「Apache MPM」 http //tkusano.asablo.jp/blog/2006/11/10/745619
https://w.atwiki.jp/ge_fast/pages/231.html
FAST党とは!? FAST党ってどんな党? グラナドエスパダのアゲートサーバーで活動している、党(=ギルド)です。 グラナドエスパダを楽しむ!というのを目標としており、 普段のスクワッドから、ボス戦、コロニー戦まで幅広く活動しています。 基本的に、自分のペースでコツコツと! FAST党での普段の生活 FAST党内では普段のイベントやボス戦、コロニー戦などの参加は基本的に自由です。 しかし、党内でなにかしら行うという声があった場合は都合がよい場合、参加したほうが楽しいかと思います。 最近は育成なども落ち着き、PvPなどのテクニックを研鑽している方も多くなってきました。 また、無心でハンティングなどばかりしているとついついソロハントになりやすいグラナドエスパダですが、 党内でのSQの参加や募集は積極的に行うと普段のプレイも楽しめるかと思います。 党内のSQはレベリングより、レイドや中ボスのヘルプなどが主体になっています。 FAST党のレイド レイドは基本的に参加自由です。 しかし、党内チャットで声がかかった際には積極的に参加していただくとよいと思います。 慣れてくるとついつい作業的になりやすいレイドですが、 FAST党では党員の皆様に新しいチャレンジをできるようにしています。 今までにやったことのない役割などに積極的に挑戦してください! FAST党のコロニー戦 ほぼ毎週行っています。参加は個人の自由です。 しかし、参加していない方も町以外のマップ上では敵対党の攻撃を 受けてしまうのでその点はご注意ください。 FAST党は他のコロニー参戦党に比べ、装備で劣り、人数が少ないため 一人ひとりのプレイスキルを発揮し活躍する環境となっています。 また普段は自由なFAST党ですが、コロニー戦やレイドなどのチーム戦の場合は 統制の取れた行動を目指しております。 勝手な行動は慎んでいただくようお願いいたします。 党ステータス(5点満点) 党員数 ★★★ アゲート的にはちょっと少なめ? 接続率 ★★★★ Oβからの党ですが、7割超えてます 戦闘力 ★★★ なんとも言えない・・・ PVP ★★★★ 好きな人が増えてまいりました! GvG ★★★ 毎週土曜日のコロニー戦はほぼ欠かしません レイド ★★★★ 毎日何かしらやってます 気 合 ★★★★★ これが無けりゃ今が無い 真面目 ★★★★ 実は結構ていうか、かなり真面目です 芸 術 ★★★★★ イラストとか描くのが好きな人もチラホラ エ ロ ★★★? なんとも言い難い・・・ その他 FAST党はアゲート全ての他党が強敵(とも)! 協力する所は協力し、競い合うところは競います。
https://w.atwiki.jp/ge_fast/pages/93.html
FAST党員の作品展示室 ここについて 党員が作ったり造ったり創ったりしたのを晒していきます(゚∀゚ページ消したってログから拾います、クククちなみに、→に行くほど新しい作品です。 フッチ画伯 ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ じゅる画伯 ■ ■ ■ 一平画伯 ■ 作者不明 ■ ■ チョコ君のとこに描いてあった落書き3点消えてる…… 誰だ消したヤツヽ(`д´)ノ あ、描いた順番・作者等間違ってたら指摘ヨロピク みなさん絵はどうやって描いてるんですか? -- (ent) 2006-10-19 02 10 00 わちしの場合はパソコンにタブレットを接続してそのまま描きます。下書きさえしませんですよ・・・ -- (レインベル) 2006-10-19 03 14 49 基本的にはベルさんと一緒かな?ただ闇雲に描き始めて、結局消すのがオチだけど(´ω` -- (beato) 2006-10-25 09 28 14 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/youyouhaku1928/pages/43.html
#! /usr/local/bin/perl # # id=form2r.cgi # # FORM2.CGIで書き込んだファイルを読み表示する # update. 00.2.13 # ファイル名 $file = "../form1.dat"; # ブラウザに出力 print "Content-type text/html\n\n"; print "\n\n"; print "\n"; print "\n\n"; print "ファイルの内容を表示します\n"; print ""; # 1.ファイルを読み出しモードでオープン open(DATA,"$file"); # 2.読み込み、 WHILE命令により、ファイルの最後まで1行ずつ読み込み表示します # わかりやすくするため、改行させて表示させます while() { print ; print ;} # 3.ファイルを閉じます close(DATA); print "\n\n"; ################## end of script ##################
https://w.atwiki.jp/cgiprowiki/pages/16.html
独自CGIを設置したけどがうまく動作しなかったら... レンタルサーバーの機能説明に独自CGIが利用可能とかPerlがインストールされていると記述されているのに、うまく動作しなかった場合は、次のことを確認してみて下さい。 1)CGIをアップロードするディレクトリに制限がないか? サーバーによっては、「cgi-bin」というディレクトリに制限している場合があります。 どうしてもドキュメントルートにCGIをアップロードして動作させたい場合は、3)を試してみて下さい。 2)Perlのパスが誤ってないか? 一般には、 /usr/bin/perl /usr/local/bin/perl に設定してある場合があります。 ※ Perlのパスは、「.cgi」という全てのファイルの1行目に記述してあります。 3)「.htaccess」というファイルに設定を記述してアップロードする必要がないか? 通常、レンタルサーバーでは、HTMLファイルと同じドキュメントルートにCGIを設置しても実行出来るようになっています。しかし、稀にCGIは、cgi-binディレクトリに設置しないと動作しないレンタルサーバーがあります。私の契約しているwappyというレンタルサーバーがそうです。 そんな時、テキストエディタを使って、以下の内容を「.htaccess」というファイル名で保存し、ドキュメントルートにアップロードしてみて下さい。たぶん、CGIをドキュメントルートに設置しても動作するようになると思います。 <.htaccess の内容> DirectoryIndex index.html index.html.var index.cgi index.php Options +ExecCGI AddHandler cgi-script .cgi AddHandler cgi-script .pl AddHandler cgi-script .pm
https://w.atwiki.jp/studymcl/pages/34.html
Perl Perl perl_5.6.1-8.3-5_arm.ipkをインストール。 (このパッケージには,以下のモジュールが既に含まれている) libCGI-perl_5.6.1-2.97_arm.ipk libClass-perl_5.6.1-030721_arm.ipk libFile-perl_5.6.1-030721_arm.ipk libTime-perl_5.6.1-030721_arm.ipk インストール後に「インストールエラー」と出て「このソフトウェアは、他のソフトウェア(ライブラリなど)を必要としています~」とあるが無視してOK。 正しくインストールされていれば,次のコマンドでPerlのバージョン情報が出る。 bash-2.05$ perl -v This is perl, v5.6.1 built for arm-linux Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl or `perldoc perl . If you have access to the Internet, point your browser at http //www.perl.com/, the Perl Home Page. Perl実行時に以下のようなwarningが出ることがある。 perl warning Setting locale failed. perl warning Please check that your locale settings LANGUAGE = (unset), LC_ALL = (unset), LANG = "ja" are supported and installed on your system. perl warning Falling back to the standard locale ("C"). 実害はないが,気になる場合は「/home/zaurus/.bashrc」と「/home/root/.bashrc」に以下を追加する。 export PERL_BADLANG=0 (これだけではエラーがなくならなかったので,パーミッションを775に変えてみたがどうなんだろう……) Perlの実行 /home/zaurusにhello.plを作る。 # vi ./hello.pl my $message = "Hello, World!\n"; print $message; これを実行。 $ perl hello.pl Hello, world! 次に,ファイル名だけで実行するようにする。 !#/usr/bin/perl my $message = "Hello, World!\n"; print $message; とし, # chmod 775 ./hello.pl でパーミッションを与えて実行すると $ ./hello.pl Hello, world! これでOK。 CGI実行環境 Apacheを参照。 ref ハッキングLinuxザウルス Walrus, Visit.さん